IBIS Macromodel Task Group Meeting date: 10 July 2012 Members (asterisk for those attending): Agilent: Fangyi Rao Radek Biernacki Altera: * David Banas * Julia Liu Hazlina Ramly Andrew Joy Consulting: Andy Joy Ansys: Samuel Mertens * Dan Dvorscak * Curtis Clark Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma Feras Al-Hawari Celsionix: Kellee Crisafulli Cisco Systems: Ashwin Vasudevan Syed Huq Ericsson: Anders Ekholm IBM: Greg Edlund Intel: * Michael Mirmak LSI Logic: Wenyi Jin Maxim Integrated Products: Mahbubul Bari Mentor Graphics: * John Angulo Zhen Mu * Arpad Muranyi Vladimir Dmitriev-Zdorov Micron Technology: Randy Wolff NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: * Eckhard Lenski QLogic Corp. James Zhou Sigrity: * Brad Brim Kumar Keshavan Ken Willis SiSoft: * Walter Katz Todd Westerhoff Doug Burns * Mike LaBonte Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla The meeting was led by Arpad Muranyi ------------------------------------------------------------------------ Opens: - Michael M: Is there a requirement that we will document the portion of traditional IBIS files that are used for AMI? - There is variability in how this is being interpreted - Walter: I can start an email thread on that -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Bob to propose a simpler way for addressing the needs of parameter passing under [External Model] and [External Circuit] - not done ------------- New Discussion: Arpad showed an MCP presentation from Brad Brim: - Slide 1: - Brad: Not much has changed in this presentation since DesignCON - Arpad: This in on the IBIS website - Slide 2: - Brad: The objective is a standard format to connect any model type with any other - It is not necessary to have the same pin names, locations can be used - Locations are X/Y value only, they are not 3D - It is multi-vendor, this has been shared with Cadence and others - Slide 4: - Brad: There can be thousands of pin connections - We need to distinguish carefully between "node" and "physical pin" - Slide 5: - Brad explained the keywords - Michael M: Who generates this file? - Brad: The electrical model generator - Arpad: How does the package model maker know the PCB connections? - Brad: The package has circuits with the pin names that are to be used - There can be name mismatches like A1 vs. A01 - Michael M: It is up to IC vendors to create mappings for packages - Brad: Agree - David: The distinction between pin and node here is due to the way we extract? - Brad: Yes, it allows things to be shorted together - Arpad: Could there be redundant and conflicting information? - Brad: There must be a tolerance on x/y locations or intelligent node matching - Not everyone supports this - David: Could a "center of mass" pin be used to short things together? - Brad: No, they have to be on individual lines - Slide 6: - Walter: I have an additional presentation that may help - Brad: This is color coded with red and blue - David: Where do the models exist? - Arpad: They go where it says "SPICE elements" near the bottom - David: So it is in the same file - Brad: Design databases often have things rotated, so some work is needed to match up - Arpad: How is it useful to have this in the model? - Brad: In PI and SI few people use schematics, they use netlists - The automation of making connections avoids mistakes - In CST and HFSS few pins are used, no problem - Larger than that and automation is required because there are so many connections - Arpad: How will the PCB software know how to set this up? - Brad: The PCB symbols will have the needed information - Arpad: We should address how this helps IBIS, since this is a SPICE comment format - We have existing formats to solve pieces of this - Brad: MCP can be added to existing formats like EBD, etc. - It is important to allow full flexibility, not requiring things to be shorted for example - Michael M: MCP is better for post-layout as opposed to pre-layout? - Brad: This is for more complex topologies like multi-die packages - Arpad: We discussed my proposal a few weeks ago, which can handle that - But it is node name based Walter showed an email draft on package and on-die modeling: - Walter described calculations of pin counts for a few interface technologies - Walter described a series topology from one chip to another in a system - There is a distinction in port counts between a low frequency model and a full model - Brad: Despite the different port counts the number of physical elements is unchanged - Walter: In some cases only an 8 bit slice of a bus might be simulated - We also have to consider when/where there is coupling between signals and between power and signals - The IC vendor and system designer may need different models - We have multiple protocols to associate package pins to board pins - IBIS desperately needs to handle uncoupled and diff coupled signal models well - This is needed for both package and on-die parasitics - The MCP proposal is about application-specific models - Users will need to extract sub-slices from the package and on-die models ------------- Next meeting: 17 Jul 2012 12:00pm PT Next agenda: 1) Task list item discussions ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives